Gaming software authentication

ABSTRACT

A method for run-time authentication of memory contents of a gaming machine includes the acts of conducting a wagering game on the gaming machine and, during the conducting step, authenticating a high capacity memory in a first authentication cycle. The high capacity memory contains program code for operating a wagering game at the gaming machine and the first authentication cycle includes the acts of reading data from the high capacity memory, generating first authentication data corresponding to the data files, and verifying the first authentication data. The method also includes, during the conducting step, authenticating at least one other memory in the gaming machine in a second authentication cycle, including processing second authentication data of a data file within the at least one other memory.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.10/119,663, filed Apr. 10, 2002, entitled “Gaming SoftwareAuthentication,” now pending, and claims priority therefrom.

FIELD OF THE INVENTION

The present invention relates generally to gaming machines and, moreparticularly, to software authentication in a gaming machine.

BACKGROUND OF THE INVENTION

As a regulatory requirement in virtually all jurisdictions that allowgaming, it is necessary to have a technique to authenticate that thesoftware installed in a gaming machine is tested and approved. In thepast, gaming manufacturers have generally used EPROM-based hardwareplatforms to store program code. As a result, a number of softwareauthentication techniques have been accepted as standards throughout thegaming industry. Depending upon the preferences of the local regulatoryagency, these techniques generally include either a Kobetron signatureor a hash function based on the data stored in the EPROM device.

Authentication of software programs basically occurs using two differentmethods in the field, again determined by the local regulatory agency.In one method, each EPROM is authenticated by a gaming agent prior tobeing installed in a gaming machine that is to be brought up for play.The EPROMs may be shipped directly to the gaming agency forauthentication prior to the install date of the machine, or may beauthenticated on the casino floor as the software is being installed inthe machine. In another method, authentication is conducted on aspot-check basis. A gaming agent periodically visits a casino and picksmachines selectively or at random to remove the software components forauthentication.

Due to advances in technology that have been made in recent years,EPROM-based hardware platforms are becoming obsolete and newertechnologies are being introduced into the gaming industry. Theseadvanced technologies utilize storage devices that have been classifiedas “high capacity storage devices.” High capacity storage devices may,for example, include CD-ROMs, hard disk drives, and flash devices. Thusfar, there is no industry standard method for authenticating these typesof devices.

SUMMARY OF THE INVENTION

A method for run-time authentication of memory contents of a gamingmachine includes the acts of conducting a wagering game on the gamingmachine and, during the conducting step, authenticating a high capacitymemory in a first authentication cycle. The high capacity memorycontains program code for operating a wagering game at the gamingmachine and the first authentication cycle includes the acts of readingdata from the high capacity memory, generating first authentication datacorresponding to the data files, and verifying the first authenticationdata. The method also includes, during the conducting step,authenticating at least one other memory in the gaming machine in asecond authentication cycle, including processing second authenticationdata of a data file within the at least one other memory.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other advantages of the invention will become apparentupon reading the following detailed description and upon reference tothe drawings.

FIG. 1 is an isometric view of a gaming machine operable to conduct awagering game.

FIG. 2 is a block diagram of computer-readable storage contained in thegaming machine.

FIG. 3 is a flow diagram of a method of generating digital signaturesfrom contents of the computer-readable storage for subsequentauthentication.

FIG. 4 is a flow diagram of a method of authenticating the digitalsignatures.

FIGS. 5 a and 5 b are a flow diagram of a multi-stage authenticationprocedure executed external to the gaming machine and then internal tothe gaming machine during a system boot process.

FIG. 6 is a flow diagram of a continuous run-time authenticationprocedure executed by the gaming machine after a main softwareapplication is launched from system RAM.

While the invention is susceptible to various modifications andalternative forms, specific embodiments have been shown by way ofexample in the drawings and will be described in detail herein. Itshould be understood, however, that the invention is not intended to belimited to the particular forms disclosed. Rather, the invention is tocover all modifications, equivalents, and alternatives falling withinthe spirit and scope of the invention as defined by the appended claims.

DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

Turning now to the drawings and referring initially to FIG. 1, a gamingmachine 10 is operable to conduct a wagering game such as mechanical orvideo slots, poker, keno, bingo, or blackjack. If based in video, thegaming machine 10 includes a video display 12 such as a cathode ray tube(CRT), liquid crystal display (LCD), plasma, or other type of videodisplay known in the art. A touch screen preferably overlies the display12. In the illustrated embodiment, the gaming machine 10 is an “upright”version in which the display 12 is oriented vertically relative to aplayer. Alternatively, the gaming machine may be a “slant-top” versionin which the display 12 is slanted at about a thirty-degree angle towardthe player.

The gaming machine 10 includes a plurality of possible credit receivingmechanisms 14 for receiving credits to be used for placing wagers in thegame. The credit receiving mechanisms 14 may, for example, include acoin acceptor, a bill acceptor, a ticket reader, and a card reader. Thebill acceptor and the ticket reader may be combined into a single unit.The card reader may, for example, accept magnetic cards and smart (chip)cards coded with money or designating an account containing money.

The gaming machine 10 includes a user interface comprising a pluralityof push-buttons 16, the above-noted touch screen, and other possibledevices. The plurality of push-buttons 16 may, for example, include oneor more “bet” buttons for wagering, a “play” button for commencing play,a “collect” button for cashing out, a “help” button for viewing a helpscreen, a “pay table” button for viewing the pay table(s), and a “callattendant” button for calling an attendant. Additional game-specificbuttons may be provided to facilitate play of the specific game executedon the machine. The touch screen may define touch keys for implementingmany of the same functions as the push-buttons. Other possible userinterface devices include a keyboard and a pointing device such as amouse or trackball.

A central processing unit (CPU) controls operation of the gaming machine10. In response to receiving a wager and a command to initiate play, theCPU randomly selects a game outcome from a plurality of possibleoutcomes and causes the display 12 to depict indicia representative ofthe selected game outcome. In the case of slots, for example, mechanicalor simulated slot reels are rotated and stopped to place symbols on thereels in visual association with one or more pay lines. If the selectedoutcome is one of the winning outcomes defined by a pay table, the CPUawards the player with a number of credits associated with the winningoutcome.

The CPU includes a microprocessor and computer-readable storage.Referring to FIG. 2, in a preferred embodiment, the computer-readablestorage includes a boot memory 20, a high capacity storage memory 22,and a serial read-write memory 24. The boot memory 20 is preferably aread-only memory such as a one megabit EPROM. The high capacity storagememory 22 is preferably a compact flash card. The serial memory 24 ispreferably an EEPROM such as a 512 byte SPI EEPROM. Depending upon thepreferences of the local regulatory agency, all three memories may beauthenticated both outside of the CPU and then when installed in the CPUat power up. The diagram in FIG. 2 displays the contents stored in eachof the memories and authenticated prior to use in the gaming machine.

The boot memory 20 stores boot code, an authentication program, a RAMloader, a decompression utility 120, and a digital signature 30. Theauthentication program includes a hash function 42, a digital signaturealgorithm (DSA) verify operation 44 a, and a public key 46 a. The hashfunction 42 may, for example, be an SHA-1 hash algorithm that reduces adata set to a unique 160 bit message digest. The digital signature 30 isgenerated from the boot memory's contents as a whole.

The high capacity storage memory 22 stores game and operating systemexecutable program files, sound operating system files, sound bankfiles, graphics files, a manifest file, and a digital signature 32. Theabove files, taken together, constitute a “game data set” as that termis used herein, and the various files constitute “data files” as thatterm is used herein. Thus, the game data set includes a plurality ofdata files. For each data file on the high capacity storage memory 22,the manifest file contains a file name, a file type, a load address, anda digital signature 34. The digital signature 32 is generated from thegame data set as a whole, while each digital signature 34 is generatedfrom the associated data file listed in the manifest file.

The serial memory 24 stores information specific to the jurisdictionwhere the CPU is to be installed. This information may, for example,include a lottery terminal identification (ID), a part number, ajurisdiction ID, a jurisdiction name, jurisdiction bit code options,jurisdiction max bet, jurisdiction max win, and a digital signature 36.The digital signature 36 is generated from the serial memory's contentsas a whole.

The digital signatures 30, 32, 34, and 36 in the various memories arepreferably generated and authenticated using the Digital SignatureStandard as adopted by the U.S. Department of Commerce/NationalInstitute of Standards and Technology and published in FIPS PUB 186-2 onJan. 27, 2000.

FIG. 3 illustrates a method of generating the digital signatures 30, 32,34, and 36 for subsequent authentication. The method is performedoutside of the gaming machine during an engineering release process.Specifically, each digital signature is generated from associated memorycontents 40 by reducing the contents 40 to a message digest 48 using thehash function 42 and then inputting the message digest 48 and a privatekey 46 b into a DSA generation operation 44 b.

The associated contents 40 from which each digital signature isgenerated varies as described above in connection with FIG. 2.Specifically, the digital signature 30 is generated from the contents ofthe boot memory 20 as a whole. The digital signature 32 is generatedfrom the game data set in the high capacity storage memory 22 as awhole, while the digital signatures 34 are generated from the respectivedata files (except the manifest file) making up the game data set. Someof the data files, such as the sound and graphics files, may becompressed. A compressed data file(s) may itself include a plurality ofuncompressed data files. A digital signature 34 may be generated fromthe compressed data file, and either a digital signature 34 or a messagedigest 48 may be generated from the data file prior to compression(i.e., the uncompressed data file). The digital signature 34 or messagedigest 48 generated from an uncompressed data file may be appended tothe compressed data file. The digital signature 36 is generated from thecontents of the serial memory 24 as a whole. The hash function 42 usedin the signature generation method is the same as the hash function 42stored in the boot memory 20. The aforementioned public key 46 a storedin the boot memory 20 and the private key 46 b form an associated pairin accordance with the Digital Signature Standard. The same publickey/private key pair 46 a-b is preferably used to generate andauthenticate all digital signatures. Alternatively, different publickey/private key pairs may be used to generate and authenticate one ormore of the digital signatures.

FIG. 4 illustrates a method of authenticating the digital signatures 30,32, 34, and 36 already stored in the memories. The timing of this methodis described below in connection with FIG. 5 and depends upon thedigital signature being authenticated. The method employs the bootmemory's authentication program, which includes the hash function 42,the DSA verify operation 44 a, and the public key 46 a. In theauthentication method, a fresh digital signature 50 is generated frompreviously signed memory contents 40 by reducing the contents 40 to amessage digest 48 using the hash function 42 and then inputting themessage digest 48 and the public key 46 a into the DSA verify operation44 a. The message digest 48 is also stored in a non-volatile randomaccess memory (RAM) for later use during continuous run-timeauthentication. The fresh digital signature 50 is then mathematicallycomplemented at step 52 to yield a complement 54 of the fresh signature50. The signature complement 54 is summed with the stored digitalsignature (i.e., digital signature 30, 32, 34, or 36) generated from thesame memory contents 40. If the mathematic sum 56 is zero (i.e., thefresh signature 50 matches the stored signature), authentication isdeemed a success at step 58. If, however, the mathematic sum 56 is notzero, authentication is deemed a failure at step 60.

Referring to FIGS. 5 a and 5 b, the procedure for authenticating thecontents of the memories 20, 22, and 24 is implemented in the followingdistinct stages: external component authentication, internal bootcomponent authentication, file authentication and loading, andcontinuous run-time authentication (see FIG. 6). This authenticationprocedure guarantees the integrity and security of the CPU software. Afailure detected in any one of the stages is considered a criticalfailure that must be corrected prior to any further play of the gamingmachine. The machine displays the critical failure, if detected, at step96.

External component authentication verifies the contents of the memoriesprior to placement in the gaming machine. Alternatively, if permitted bythe local gaming agency, the memory contents may be verified using adedicated serial port after the memories have been installed in the CPU.External component authentication of the boot memory 20 may beaccomplished using industry standard techniques, such as a KobetronMT-2000 signature or a hash algorithm for generating a unique signature(step 70). External component authentication of the high capacitystorage memory 22 may be accomplished using tools commercially availablefrom such companies as Kobetron Inc. of Navarre, Fla., GamingLaboratories International Inc. (GLI) of Toms River, N.J., and DatamanProgrammer Ltd. of Orange City, Fla. (step 72). External componentauthentication of the serial memory 24, which requires a serialcommunications interface to read from and write to the memory, may beaccomplished using tools commercially available from one or more of theaforementioned companies (step 74).

Internal boot component authentication occurs immediately followingpower up of the machine and entails authentication of the contents ofeach installed memory as a whole and does not look at individual filesstored in the memory. Authentication of individual files occurs during alater stage. After powering up (booting) the machine at step 76, a PowerOn Self Test (POST) is immediately initiated at step 78 to initializethe CPU hardware and run a few basic tests to verify that the hardwareis functioning correctly. After the POST, the three memories areauthenticated as a whole using the method in FIG. 4 and in the followingsequence: (1) authenticate digital signature 30 of boot memory 20 atstep 80, (2) authenticate digital signature 36 of serial memory 24 atstep 82, and (3) authenticate digital signature 32 of high capacitystorage memory 22 at step 86. The boot memory 20 is authenticated firstbecause the other two memories rely upon the contents of the boot memory20 to complete their own authentication processes. Prior toauthenticating the high capacity storage memory 22 at step 86, thatmemory's drivers and file system are initialized at step 84. If allthree memories have been determined to be both present and authentic,the authentication procedure proceeds to the next stage—fileauthentication and loading.

File authentication and loading sequentially authenticates theexecutable data files (except for the manifest file) stored in the highcapacity storage memory 22 and loads each authenticated data file intothe CPU component (e.g., system RAM) where the data file will reside andexecute from during normal machine operation. The data files are loadedand processed in the order listed in the manifest file stored in thehigh capacity storage device 22. The manifest file itself is not loadedinto the system, but rather is used during the system boot process toguide the file loading process. The order in which the data files areloaded does not have an effect on system operation.

The digital signature 34 of a data file in the high capacity storagememory 22 is authenticated at step 88 using the method in FIG. 4. If thedata file is compressed, the digital signature 34 generated from thecompressed data file is authenticated at step 88. If the digitalsignature 34 is authenticated, a check is made at step 89 as to whetheror not the data file is compressed. If the data file is not compressed,the data file is loaded to an associated CPU component at step 90. Theassociated CPU component is identified in the manifest file. If,however, the data file is compressed, the compressed data file isdecompressed using the decompression utility 120 stored in the bootmemory 20 at step 91. The decompressed data file may be authenticatedprior to being loaded to the associated CPU component at step 93. Themessage digest 48 calculated during such authentication is stored in thenon-volatile random access memory (RAM) for later use during continuousrun-time authentication. A check is then made at step 92 as to whetheror not the loaded data file was the last file listed in the manifestfile. If not, the file authentication and loading steps are repeated forthe next data file listed in the manifest file. After authenticating andloading the last file and performing a RAM clear check (not shown), themain software application is launched from system RAM at step 94 tocomplete the system boot process. The authentication procedure thenproceeds to the final stage—continuous run-time authentication.

FIG. 6 illustrates a basic method of continuous run-time authenticationas it will take place following the completion of the system bootprocess. There are two main cycles of events that occur duringcontinuous run-time authentication. The first cycle repeatedly verifiesthe presence of the high capacity storage memory 22 in the CPU board,and calculates and verifies the message digest 48 (see FIG. 4) for thememory 22 as a whole at steps 100, 102, and 104. The high capacitystorage memory 22 is accessed at short time intervals such as every 15milliseconds. Any unsuccessful read of the high capacity storage memory22 at step 100 or any unsuccessful authentication at step 104 halts themachine and causes it to display a critical error at step 96. Thecontinuous run-time authentication of the high capacity storage memory22 is limited to the memory as a whole and does not look at individualfiles stored on the memory.

The second cycle involves repetitive authentication of the serial memory24 at step 106, the boot memory 20 at step 108, and the files that areexecuting from system RAM at steps 110 and 112. All authentications arepreferably accomplished using the message digest 48 of the correspondingmemory or file, instead of the DSA verify operation in FIG. 4. Messagedigests 48 of the various memories and files (including the decompresseddata files) were previously stored in non-volatile RAM, and it isagainst these stored message digests 48 that newly calculated messagedigests are compared. The DSA verify operation is not necessary at thispoint because the memories and files were proven to be authentic duringthe system boot process. The purpose of continuous run-timeauthentication is to ensure that the information that was loaded tosystem RAM during the boot process has not been altered and that thememories have not been changed. A message digest 48 is sufficient forthis purpose. It should be understood, however, that the DSA verifyoperation may instead be performed during this second cycle ofcontinuous run-time authentication.

Following the successful authentication of all files in system RAM, thenon-volatile RAM is verified using a standard “CRC” or other similarcheck at step 114. Main and auxiliary copies of the non-volatile RAM arealso compared to each other at step 114 to ensure the integrity of thenon-volatile RAM. In accordance with step 116, all of the abovefunctions of the second cycle continue for as long as the machine ispowered on. If the machine is powered off, the authentication procedurewill start again at the boot component authentication stage in FIG. 5when the machine is powered up.

While the present invention has been described with reference to one ormore particular embodiments, those skilled in the art will recognizethat many changes may be made thereto without departing from the spiritand scope of the present invention.

For example, as noted above, numerous techniques may be used to prepareand authenticate a compressed data set. The compressed data set mayinclude one or more files in the high capacity storage memory 22. In theillustrated embodiment, to prepare a compressed data set for subsequentauthentication, the performed steps include compressing an uncompressedgame data set; generating a first authentication code from thecompressed data set; and storing the compressed data set and the firstauthentication code in the high capacity storage memory 22. Thecompressed data set may include sound files, graphics files, and evenexecutable game code. The first authentication code may be a messagedigest 48 or a digital signature 34 (see FIG. 3). The manifest file inthe high capacity storage memory 22 lists the compressed data set andits associated first authentication code.

Prior to compressing an uncompressed data set, a second authenticationcode may be generated from the uncompressed data set and appended to thecompressed data set. The second authentication code may be a messagedigest 48 or a digital signature 34 (see FIG. 3). The manifest file inthe high capacity storage memory 22 lists the compressed data set andthe first and second authentication codes generated from the respectivecompressed and uncompressed data sets.

To authenticate a data set that has been prepared in the above manner,the performed steps include authenticating the compressed data set;decompressing the compressed data set using a decompression utilitystored in the boot memory; and authenticating the decompressed data set.Both the compressed data set and the decompressed data set may beauthenticated during the file authentication and loading stage shown inFIG. 5 b by generating fresh authentication codes that are compared tothe respective stored first and second authentication codes. If a storedauthentication code is a message digest 48 (see FIG. 3), then the freshauthentication code against which it is compared is also a messagedigest (see FIG. 4). If, however, the stored authentication code is adigital signature 34 (see FIG. 3), then the fresh authentication codeagainst which it is compared is a digital signature 50 (see FIG. 4).After the decompressed data set is loaded into its associated CPUcomponent (e.g., system RAM), the decompressed data set may again beauthenticated during continuous run-time authentication shown in FIG. 6by generating a fresh authentication code that is compared to the storedsecond authentication code of the same type (i.e., message digest ordigital signature).

The compressed data set may include a plurality of uncompressed datafiles. When preparing the compressed data set for subsequentauthentication, a respective authentication code may be generated foreach of these uncompressed files and stored in the manifest file. Theseauthentication codes are then later authenticated after decompressingthe compressed data set.

Depending upon the level of authentication needed to comply with aregulatory gaming body, the authentication method may be modified toauthenticate the compressed data set only prior to decompression or onlyafter decompression.

Each of these embodiments and obvious variations thereof is contemplatedas falling within the spirit and scope of the claimed invention, whichis set forth in the following claims:

1. A method for run-time authentication of memory contents of a gamingmachine, comprising: conducting a wagering game on the gaming machine;during said conducting step, authenticating a high capacity memory in afirst authentication cycle, the high capacity memory containing programcode for operating a wagering game at the gaming machine, the firstauthentication cycle including reading data from the high capacitymemory, generating first authentication data corresponding to the datafiles, and verifying the first authentication data; and during saidconducting step, authenticating at least one other memory in the gamingmachine in a second authentication cycle, including processing secondauthentication data of a data file within the at least one other memory.2. A method as recited in claim 1, wherein the first authentication datais a first message digest and the second authentication data is a secondmessage digest.
 3. A method as recited in claim 1, wherein the firstauthentication data is a first signature and the second authenticationdata is a second signature.
 4. A method as recited in claim 1, whereinthe program code stored in the first memory is a game data set andwherein files stored in the at least one other memory include at leastone of boot code, jurisdiction specific data, data identifying thegaming machine, and authentication data.
 5. A method as recited in claim1, wherein said first authentication cycle and said secondauthentication cycle are conducted repeatedly.
 6. A method as recited inclaim 1, wherein said second authentication cycle further comprisesverifying a non-volatile random access memory (RAM) of the gamingmachine that is used to store authentication data.
 7. A method asrecited in claim 1, wherein said second authentication cycle comprisesauthenticating a serial memory of the gaming machine, authenticating aboot memory of the gaming machine and authenticating files that areexecuting from system random access memory (RAM) of the gaming machine.8. A method as recited in claim 1, wherein verifying the firstauthentication data is accomplished by applying a DSA verify operation.9. A method as recited in claim 1, wherein processing the secondauthentication data is accomplished by comparing the secondauthentication data to corresponding authentication data stored innon-volatile random access memory (RAM).
 10. A method as recited inclaim 1, wherein said first authentication cycle comprisesauthenticating the contents of the high capacity memory as a whole. 11.A method as recited in claim 1, wherein said second authentication cyclecomprises authenticating one or more individual files stored in the atleast one other memory device.
 12. A method as recited in claim 1wherein said first authentication cycle and said second authenticationcycle occur concurrently.
 13. A method for run-time authentication ofcontents of a high capacity memory of a gaming machine, comprising:conducting a wagering game on the gaming machine by executing, with aprocessor, program code stored on a high capacity memory of the gamingmachine; authenticating the high capacity memory of the gaming machinein a first authentication cycle during said step of conducting; andauthenticating at least one other memory in the gaming machine in asecond authentication cycle during said step of conducting.
 14. A methodas recited in claim 13, wherein said step of authenticating a highcapacity memory comprises reading data files from the high capacitymemory, generating first authentication data corresponding to the datafiles, and verifying the first authentication data, and wherein saidstep of authenticating at least one other memory in the gaming machinecomprises processing second authentication data of a data file withinthe at least one other memory.
 15. A method as recited in claim 14,wherein the first authentication data is a first message digest and thesecond authentication data is a second message digest.
 16. A method asrecited in claim 14, wherein the first authentication data is a firstsignature and the second authentication data is a second signature. 17.A method as recited in claim 13, wherein the program code stored in thefirst memory is a game data set and wherein files stored in the at leastone other memory include at least one of boot code, jurisdictionspecific data, data identifying the gaming machine, and authenticationdata.
 18. A method as recited in claim 13, wherein said firstauthentication cycle and said second authentication cycle are conductedrepeatedly.
 19. A method as recited in claim 13, wherein said secondauthentication cycle further comprises verifying a non-volatile randomaccess memory (RAM) of the gaming machine that is used to storeauthentication data.
 20. A method as recited in claim 13, wherein saidsecond authentication cycle comprises authenticating a serial memory ofthe gaming machine, authenticating a boot memory of the gaming machineand authenticating files that are executing from system random accessmemory (RAM) of the gaming machine.
 21. A method as recited in claim 13,wherein verifying the first authentication data is accomplished byapplying a DSA verify operation.
 22. A method as recited in claim 13,wherein processing the second authentication data is accomplished bycomparing the second authentication data to corresponding authenticationdata stored in non-volatile random access memory (RAM).
 23. A method asrecited in claim 13, wherein said first authentication cycle comprisesauthenticating the contents of the high capacity memory as a whole. 24.A method as recited in claim 13, wherein said second authenticationcycle comprises authenticating one or more individual files stored inthe at least one other memory device.
 25. A method as recited in claim12 wherein said first authentication cycle and said secondauthentication cycle occur concurrently.
 26. A gaming machine forconducting a wagering game, said gaming machine comprising: a highcapacity memory having program code stored thereon; a processor forexecuting the program code to conduct a wagering game on the gamingmachine; at least one other memory; and a boot memory having anauthentication routine stored thereon, said authentication routine beingoperative, while said gaming machine is conducting a wagering game, toauthenticate the high capacity memory in a first authentication cycleand to authenticate said at least one other memory in a secondauthentication cycle.
 27. A gaming machine as recited in claim 26,wherein said authentication routine is operative to read data files fromthe high capacity memory, generate first authentication datacorresponding to the data files, and verify the first authenticationdata, and wherein said authentication routine is operative to processsecond authentication data of a data file within said at least one othermemory.
 28. A gaming machine as recited in claim 27, wherein said firstauthentication data is a first message digest and said secondauthentication data is a second message digest.
 29. A gaming machine asrecited in claim 27, wherein said first authentication data is a firstsignature and said second authentication data is a second signature. 30.A gaming machine as recited in claim 27, wherein the program code storedin the first memory is a game data set and the wherein files stored insaid at least one other memory include at least one of boot code,jurisdiction specific data, data identifying the gaming machine, andauthentication data.
 31. A gaming machine as recited in claim 27,wherein said first authentication cycle and said second cycle areconducted repeatedly.
 32. A gaming machine as recited in claim 27,wherein said second authentication cycle further comprises verifying anon-volatile random access memory (RAM) of the gaming machine that isused to store authentication data.
 33. A gaming machine as recited inclaim 27, wherein said second authentication cycle comprisesauthenticating a serial memory of the gaming machine, authenticating aboot memory of the gaming machine, and authenticating files that areexecuting from system random access memory (RAM) of the gaming machine.34. A gaming machine as recited in claim 27, wherein the verify functionof the first authentication data is accomplished by applying a DSAverify operation to the first authentication data.
 35. A gaming machineas recited in claim 27, wherein processing second authentication data isaccomplished by comparing second authentication data to correspondingauthentication data stored in non-volatile RAM.
 36. A method as recitedin claim 26, wherein said first authentication cycle comprisesauthenticating one or more individual files stored in the at least oneother memory device.
 37. A method as recited in claim 27, wherein saidauthentication second cycle comprises authenticating the contents ofsaid high capacity memory as a whole.
 38. A gaming machine as recited inclaim 26, wherein the first authentication cycle and the secondauthentication cycle occur concurrently.